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REMARKS 

Claims 1-24 are pending in the Application, and all claims have been rejected in 
the Office action mailed March 20, 2008. No claims are amended by this response. 
Claims 1,16, and 22 are independent claims. Claims 2-15, 17-21, and 23-24 depend 
from independent claims 1,16, and 22, respectively. 

The Applicant respectfully requests reconsideration of pending claims 1-24, in light 
of the following remarks. 

Objection to Declaration 

Applicant respectfully notes that the Examiner has indicated at Box 1 1 on the Office 
Action Summary, form PTOL-326, that the oath or declaration is objected to. However, 
the Detailed Action makes no mention of an objection to the declaration, and a form PTO- 
152 is not attached. In the absence of any supporting grounds for such an objection, 
Applicant assumes that the marking of Box 11 was in error, and that the declaration is 
acceptable to the Office. 

Rejection of Claims 
Rejections under 35 U.S.C. §101 

Claims 1-21 were rejected under 35 U.S.C. §101. The Office asserts that the 
claimed invention is directed to non-statutory subject matter. Applicant respectfully 
traverses the rejection. 

Applicant believes that the subject matter of claims 1-21 is statutory, and 
respectfully submits that the compliance of claims 1-21 with 35 U.S.C. §101 has been 
established by a prior examiner. According to M.P.E.P. §704.01, the action of one 
Examiner should be given full faith and credit by a subsequent Examiner: 

When an examiner is assigned to act on an application which has 
received one or more actions by some other examiner, full faith and credit 
should be given to the search and action of the previous examiner unless 
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there is a clear error in the previous action or knowledge of other prior art. In 
general the second examiner should not take an entirely new approach to 
the application or attempt to reorient the point of view of the previous 
examiner, or make a new search in the mere hope of finding something. See 
MPEP§ 719.05. 

The Office action mailed April 19, 2007, which was prepared by Primary Examiner 
Mary J. Steelman, set forth a rejection of claims 1-21 under 35 U.S.C. §101 as being 
directed to non-statutory subject matter. See Office action of April 19, 2007 at page 2. 
Applicant amended claims 1-21 in the response filed July 19, 2007, in accordance with the 
Examiner's rejection. See Response of July 19, 2007 at pages 2-7 and 10. The rejection 
of claims 1-21 under 35 U.S.C. §101 was withdrawn by Examiner Steelman in the next 
Office action. See Office action of October 2, 2007 at page 2. Applicant respectfully notes 
that, although the Office action of October 2, 2007 states that "[i]n view of the amendment 
to claim 1, the prior 35 U.S.C. 101 rejection is hereby withdrawn...", the failure to 
enumerate all of the claims rejected under 35 U.S.C. §101 is assumed by the Applicant to 
be a typographical error, in that the Office does not set forth a 35 U.S.C. §101 rejection of 
claims in the Application. 

Applicant is confident that both Primary Examiner Steelman and the present 
Examiner have fulfilled their obligations to thoroughly examine the Application and the 
prior art, as set forth in 37 C.F.R. §1 .1 04, which states in part: 

On taking up an application for examination or a patent in a 
reexamination proceeding, the examiner shall make a thorough study 
thereof and shall make a thorough investigation of the available prior art 
relating to the subject matter of the claimed invention. The examination shall 
be complete with respect both to compliance of the application or patent 
under reexamination with the applicable statutes and rules and to the 
patentability of the invention as claimed, as well as with respect to matters of 
form, unless otherwise indicated. 

Applicant respectfully submits that the present Examiner has not set forth an 
argument that "...a clear error in the previous action or knowledge of other prior art..." is 
the cause of the present rejection of claims 1-21 under 35 U.S.C. §101. Applicant also 
respectfully submits that independent claims 1 and 16, from which claims 2-15 and 17-21 
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respectively depend, were not amended following withdrawal of the 35 U.S.C. §101 
rejection of claims 1-21 by the prior Examiner. Therefore, Applicant respectfully submits 
that the status under 35 U.S.C. §101 of claims 1-21 did not change following Examiner 
Steelman's decision to withdraw the 35 U.S.C. §101 rejection of claims 1-21, and that 
claims 1-21 still recite statutory subject matter in compliance with 35 U.S.C. §101 . 
The instant Office action states at pages 2-3: 

Claim 1 recites a system comprising of a service broker and claim 16 
recites a system comprising of a service broker, service providers and client- 
side component. The service broker, service providers, and client-side 
components are interpreted as software only and are functional descriptive 
material. ... Since claims 1 and 16 do not recite the service broker, service 
providers and client-side component as being recorded on a computer- 
readable medium, the system are [sic] interpreted as comprising functional 
descriptive material per se and non statutory. See MPEP §2106.01 . 

Applicant respectfully disagree with this interpretation of claims 1 and 16, and 
submits that the Office has failed to set forth grounds for such a narrow interpretation of 
the claims. As is clearly illustrated in Fig. 1 of the Application, an example of a service 
broker is shown as element 127 (a "service broker server") in Fig. 1 of the Application. 
Applicant respectfully submits that there is nothing in the ordinary meaning of the term 
"service broker" that makes it inherently software, and that one of ordinary skill in the art 
would not place such a limitation on the meaning of the term. For at least this reason, 
Applicant respectfully submits that the interpretation of the Office is unnecessarily limiting, 
and that claims 1 and 16 describe statutory subject matter. 

Therefore, for at least the reasons set forth above, Applicant believes that claims 1 
and 16, and any claims that depend therefrom, recite statutory subject matter, and 
respectfully requests that the rejection of claims 1-21 under 35 U.S.C. §101 be 
reconsidered and withdrawn. 
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Rejections under 35 U.S.C. §103 

Claims 1-24 were rejected under 35 U.S.C. §1 03(a) as being unpatentable over 
Tavis et al. (US 20030084138, hereinafter "Tavis") in view of Chamberlain et al. (US 
6,317,880, hereinafter "Chamberlain"). Applicant respectfully traverses the rejections. 

Applicant respectfully submits that the Office action has failed to establish a prima 
facie case of obviousness, in accordance with M.P.E.P. §2142. According to M.P.E.P. 
§2142, "[t]he examiner bears the initial burden of factually supporting any prima facie 
conclusion of obviousness. If the examiner does not produce a prima facie case, the 
applicant is under no obligation to submit evidence of nonobviousness." M.P.E.P. §2142 
further states that "[t]he key to supporting any rejection under 35 U.S.C. 103 is the clear 
articulation of the reason(s) why the claimed invention would have been obvious." As 
recognized in M.P.E.P. §2142, "[t]he Supreme Court in KSR International Co. v. Teleflex 
Inc., 127 S. Ct. 1727 (2007), 82 USPQ2d 1385, 1396 noted that the analysis supporting a 
rejection under 35 U.S.C. 103 should be made explicit." In addition, the Federal Circuit 
has made clear that "rejections on obviousness cannot be sustained with mere conclusory 
statements; instead, there must be some articulated reasoning with some rational 
underpinning to support the legal conclusion of obviousness." In re Kahn, 441 F.3d 977, 
988, 78 USPQ2d 1329, 1336 (Fed. Cir. 2006). See also KSR, 127 S. Ct. 1727 (2007), 82 
USPQ2d at 1396. 

With regard to the rejection of independent claim 1, Applicant respectfully 
submits that claim 1 recites "[a] system that facilitates interactions between one of a 
plurality of software components in an electronic device and an associated one of a 
plurality of servers, via a network, the system comprising: a service broker capable of 
receiving at least one request for service associated with one of the plurality of software 
components; the service broker capable of determining the one of the plurality of 
servers associated with the one of the plurality of software components, based upon a 
prior registration associating the one of the plurality of servers with the one of the 
plurality of software components making the at least one request for service; and the 
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service broker capable of forwarding the at least one request for service to the 
determined one of the plurality of servers." 

The Office asserts that Tavis teaches "...a service broker capable of receiving at 
least one request for service associated with one of the plurality of software 
components [local component manager, such as component manager 110 or 112, can 
determine if a component update request will result in a component download; pp. 2-3, 
paragraph 0033];...." See Office action at page 4. Applicant first addresses cited 
paragraph [0033] of Tavis, which states: 



A special single component manager instance, called a system 
component manager 116, operates in the master process 100 and is 
forwarded all component update requests from all other component 
managers 110 and 112, via the component request queue 114. A local 
component manager, such as component manager 110 or 112, can 
determine if a component update request will result in a component 
download, but only the system component manager 116 actually performs 
downloads and installations. The system component manager 116 also 
handles tasks, such as polling for new versions of installed components 
on time-driven events associated with the installed components (for 
example, components can "expire" as discussed below). The system 
component manager 116 also coordinates the shutdown of certain 
processes that normally run continuously. 



In light of the above, Applicant understands the Office to be asserting that the 
"component manager 110 or 112", the "component update request", and the 
"component/software component" of Tavis teach, respectively, the "service broker", the 
"at least one request for service", and the "one of a plurality of software components" 
elements of Applicant' claim 1. Applicant also understands the Office to be asserting 
that the requested "service" of Applicant' claim 1 is taught by the "component update" of 
Tavis. 

To better understand the teachings of paragraph [0033] of Tavis regarding a 
"request", Applicant turns to the paragraph immediately before cited paragraph [0033], 
paragraph [0032], which states: 
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Each component manager object 110 and 112 receives "requests" 
for components and determines if, and when, the components need to be 
retrieved and installed on the local device. A request is a signal to the 
component manager that some entity needs a specific component to be 
available on the local device. These requests can arrive from remote client 
installations, be locally created by the instantiation of a tool template, or be 
generated by the component manager itself as a result of polling for newer 
versions of already installed components. 

This portion of Tavis explains that "requests for components" are received by 
"component manager object 110 and 112", and that a "request" is "a signal" that "some 
entity" needs a specific software component to be available on the local device. Tavis 
also explains that "requests" can arrive from "remote client installations, be locally 
created by the instantiation of a tool template, or be generated by the component 
manager itself...." Applicant respectfully submits, however, that the cited portion of 
Tavis at paragraph [0033] fails to teach or suggest that a "request" to make a "specific 
software component" available is actually made by the "specific software component" 
itself. Instead, Tavis teaches that the "requests" can arrive from "...remote client 
installations, be locally created by the instantiation of a tool template, or be generated 
by the component manager itself as a result of polling for newer versions of already 
installed components." 

The Office then goes on to state that Tavis teaches "...the service broker capable 
of determining the one of the plurality of servers associated with the one of the plurality 
of software components [system component manager 116 can cause a download of a 
component file from the location from which the component was originally retrieved and 
check to determine whether the component file references a newer component; p. 4, 
paragraph 0048];...." See Office action at page 4. By this statement, Applicant 
understands the Office to be asserting that "...the location from which the [software] 
component was originally retrieved..." somehow teaches Applicant's element "one of 
the plurality of servers". 

As an initial matter, Applicant respectfully submits that, although the Office 
previously identified the "component manager object 110 and 112" as teaching the 
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"service broker" element of Applicant' claim 1, the Office now appears to suggest that 
Applicant's "service broker" element is taught by the "system component manager 116" 
of Tavis. Applicant respectfully submits that a prima facie case of obviousness cannot 
be established based upon such an inconsistency in the interpretation of teachings of a 
reference. 

Further, the Office has failed to show where Tavis teaches that either of 
"component manager object 110 and 112" and "system component manager 116", in 
fact, "...determin[e] the one of the plurality of servers associated with the one of the 
plurality of software components...", as recited by claim 1. To the contrary, Tavis 
clearly states in paragraph [0033] (cited by the Office) that "system component manager 
116" is "...forwarded aN component update requests from all other component 
managers 110 and 112." (emphasis added) Applicant respectfully submits that it 
necessarily follows that "component manager object 110 and 112" do not "...determin[e] 
the one of the plurality of servers associated with the one of the plurality of software 
components...", as recited by claim 1, but merely pass aN component update requests 
to "system component manager 116". Therefore, Applicant respectfully submits that the 
"component manager object 110 and 112" of Tavis does not teach or suggest, at least, 
"...the service broker capable of determining the one of the plurality of servers 
associated with the one of the plurality of software components...", as recited by 
Applicant' claim 1 . Further, Applicant also respectfully submits that the Office has also 
failed to show where "system component manager 116" of Tavis teaches this aspect of 
Applicant' claim 1 . Tavis discloses at paragraphs [0034] and [0035], the following: 

The system component managers 116 works in conjunction with a 
download manager 130 and an install manager 132. The download 
manager 130 retrieves components designated by the system component 
manager 116 from a server over a network, such as the Internet, and the 
install manager 132 installs retrieved components in the local system. The 
system component manager 116 communicates with the download 
manager 130 via the download request queue 118, and communicates 
with the install manager 132 via the install request queue 120. 

The download manager part 130 of the master process 100 is 
responsible for servicing requests to retrieve software components from 
the Internet. As discussed below, each component is identified by a 
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Uniform Resource Locator (URL) that is passed to the download manager 
130 by the system component manager 116 to begin the download 
process. The download manager 130 works with the network transport 
layer of a network protocol stack in order to retrieve components without 
interfering with the normal transfer of information between collaborators, 
via deltas. The system component manager 116 and the download 
manager 130 communicate by exchanging information via the download 
request queue 118 which can be an element queue as described in 
aforementioned application, Ser. No. 09/588,195. 



The portions of Tavis shown above explain that the "system component manager 
116" works with a "download manager 130", which services request to retrieve software 
components from the Internet. The software components are identified by a URL 
passed to the "download manager 130" by the "system component manager 116". The 
Office has failed to show how the "system component manager 116" operates to 
"...determinefe] the one of the plurality of servers associated with the one of the plurality 
of software components...", in accordance with claim 1. Tavis clearly states in 
paragraph [0035] that "...each component is identified by a Uniform Resource Locator 
(URL) that is passed to the download manager 130 by the system component manager 
116...." (emphasis added) Tavis does not, however, teach or suggest that the "system 
component manager 116" determines the URL. In fact, paragraph [0056] of Tavis 
states the following: 



A component update reguest that a component manager receives 
asks for a component resource by providing a URL that identifies the 
resource to the component manager . Component resource URLs always 
point to the Internet, via an HTTP or an FTP scheme. The format of a 
component resource URL has two parts separated by a "?" character. The 
following is a simple example: 
(emphasis added) 

The portion of Tavis shown above clearly states that the "component update 
request" received by a "component manager" provides the URL . Therefore, Applicant 
respectfully submits that Tavis teaches that a server accessed in responding to the 
"request" is not determined by the "component manager object 110 and 112", the 
"system component manager 116", or the "download manager 130", but is instead 
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determined by the source of the "request", in that the source of the request provides the 
URL. Applicant has shown above that Tavis teaches at paragraph [0032] that "...[t]hese 
requests can arrive from remote client installations, be locally created by the 
instantiation of a tool template, or be generated by the component manager itself as a 
result of polling for newer versions of already installed components." Again, Applicant 
respectfully submits that requests "arriving] from "remote client installations", "locally 
created by the instantiation of a tool template", and "generated by the component 
manager itself do not teach or suggest a request coming from "software components 
making the at least one request for service", in accordance with Applicant's claim 1. 
Therefore, Applicant respectfully submits that Tavis does not teach or suggest a 
"service broker", "...determining the one of the plurality of servers associated with the 
one of the plurality of software components,...", as recited by Applicant' claim 1. 

Applicant now addresses Tavis at paragraph [0048], which recites: 

The second way to trigger an update process is by polling. 
Frequently, the system component manager 116 will inspect its local 
manifest of installed components to see if any component has reached an 
update "time" that is defined by the component provider. In addition, the 
system component manager 116 can cause a download of a component 
file from the location from which the component was originally retrieved 
and check to determine whether the component file references a newer 
component. If so, the system component manager 116 will cause the 
newer component to be downloaded as well. 

This portion of Tavis simply teaches that a component update may be triggered 
by inspecting a manifest or list of installed software components to determine whether 
any component has reached an update time, or may check the location from which the 
software component was originally retrieved to determine whether a newer version is 
referenced. In either case, Applicant respectfully submits that the portion of Tavis 
shown above, specifically cited by the Office, teaches that it is the "system component 
manager 116" that is the source of a request for a component update. This, however, is 
inconsistent with the previous suggestion by the Office that one or the other of "system 
component manager 116" and the "component manager object 110 and 112" teach 
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Applicant's "service broker". Applicant respectfully submits that claim 1 recites that the 
"service broker" of Applicant' claim 1 is capable of "...receiving at least one request for 
service associated with one of the plurality of software components..." and that it is 
"...the one of the plurality of software components making the at least one request for 
service;...", not the "service broker", that makes the request. Therefore, Applicant 
respectfully submits that the cited portion of Tavis at paragraph [0048] does not teach or 
suggest at least this aspect of Applicant' claim 1 . 

In addition, the Office has not explained how and why "...download of a 
component file from the location from which the component was originally retrieved and 
check to determine whether the component file references a newer component..." 
teaches Applicant' "...determining the one of the plurality of servers associated with the 
one of the plurality of software components [making the request for service]...", in 
accordance with claim 1 . As noted above, M.P.E.P. §2142 recognizes that "[t]he key to 
supporting any rejection under 35 U.S.C. 103 is the clear articulation of the reason(s) why 
the claimed invention would have been obvious." For at least this reason, Applicant 
respectfully submits that the Office failed to show where Tavis teaches at least this 
aspect of Applicant's claim 1 . 

The Office asserts that Tavis teaches "the service broker capable of forwarding 
the at least one request for service to the determined one of the plurality of servers 
[download manager 130 retrieves components designated by the system component 
manager 116 from a server over a network such as the Internet; p. 3, paragraph [0034] 
and p. 6, paragraph [0076]. Applicant respectfully disagrees. For at least the reasons 
set forth above, Applicant respectfully submits that the "system component manager 
116" does not determine/designate the "components retrieved", in that the "system 
component manager 116" is not the source of the URL used in the retrieval. Applicant 
has previously addressed the teachings of paragraph [0034] of Tavis, above. 

Applicant now turns to the alleged teachings of paragraph [0076], which states: 

After calling the transport interface, the download manager thread 
reads from the stream pending, if necessary and writes the stream data to 
a file in the download manager staging area. The name of the file is 
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determined by the components OSD name and the staging area is 
partitioned by the URL path. The download manager also notifies the 
system component manager of its progress, via an element queue, if 
requested. Finally, when the download manager thread receives an end- 
of-stream return code, it closes the staging file and notifies the system 
component manager that the file transfer, but not the file verification, is 
complete. In a preferred embodiment, components can be downloaded 
from "component farms", which are commodity servers that host 
components available for download by the component manager. 

The portion of Tavis shown above simply teaches that a "download manager 
thread" reads from a stream and writes stream data to a file, that the "download 
manager" notifies the "system component manager" of its progress, and that "[software] 
components" can be downloaded from "commodity servers" that host [software] 
components for download by the "component manager". This portion of Tavis, which 
was specifically cited by the Office does not, however, teach or suggest, at least, "...the 
service broker capable of forwarding the at least one request for service to the 
determined one of the plurality of servers...." Instead, the Office now seems to assert 
that the "download manager 130" of Tavis teaches the "service broker" element of 
Applicant' claim 1, which the Office previously identified as corresponding to the 
"component manager object 110 and 112" and the "system component manager 116". 
Applicant respectfully submits that the Office has failed to show, for at least the reasons 
set forth above, how and why any or all of the "component manager object 110 and 
112", the "system component manager 116", or the "download manager 130" of Tavis 
teach or suggest the "service broker" element of Applicant's claim 1 . Further, the Office 
fails to show where Chamberlain remedies any of the shortcomings of Tavis set forth 
above. 

Applicant appreciates recognition by the Office that Tavis "...does not teach 
determining the one of the plurality of servers associated with the one of the plurality of 
software components based upon a prior registration associating the one of the plurality 
of servers with the one of the plurality of software components making the at least one 
request for service." See Office action at ages 4-5. The Office, however, then turns to 
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Chamberlain, and asserts that Chamberlain teaches "...an installer application 
maintains a list of source locations [col. 4, lines 26-45], and determining the one of the 
plurality of servers associated with the one of the plurality of software components 
[locations in the source list 212 are searched, and the first location having the source 
215 is used for the install; col. 9, line 60 - col. 10, line 6] based upon a prior registration 
associating the one of the plurality of servers with the one of the plurality of software 
components making the at least one request for service [installer application 201 
creates a "source list" 212 in the installer registry 202; col. 8, lines 13-36]." See Office 
action at page 5. Applicant respectfully disagrees. 

Applicant's claim 1 recites, in part, "...determining the one of the plurality of 
servers associated with the one of the plurality of software components...." Applicant 
respectfully submits that this clearly establishes one-to-one correspondence between a 
"software component" in the electronic device that makes a request, and a "server" to 
which the "request" is made. Applicant first addresses the cited portion of Chamberlain 
at column 4, lines 26-45, which states: 



Another aspect of the present invention relates to a method of 
adding a new source location to the source list. The installer application 
maintains a list of source locations and detects when a new source 
location has been identified by a user. The installer application then 
determines whether the new source location is already on the list of 
source locations. If the new source location is not on the list of source 
locations, the installer application adds the new source location to the list. 
In the disclosed embodiment the installer maintains a comprehensive list 
of source locations, which consists of network source locations, media 
source locations, and Internet site source locations. The installer 
application remembers the last-used source location and replaces the last- 
used source location with a new source location. If it is determined that the 
new source location is a media source location, this media source location 
is not added as a new source location to the list of source locations. 



The portion of Chamberlain shown above simply teaches that an "installer 
application" maintains a "source list" of "source locations" identified by a user that may 
be "network source locations", "media source locations", and "Internet site source 
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locations", and that the "installer application" remembers the "last used source location". 
Therefore, Applicant respectfully submits that the Chamberlain merely teaches the 
creation of a list of sources. Applicant understands that by the above, the Office is 
asserting that the "source list 212" of Chamberlain teaches Applicant's "...prior 
registration associating the one of the plurality of servers with the one of the plurality of 
software components making the at least one request for service...." 

The Office also cites the portion of Chamberlain at column 8, lines 13-36, which 

states: 

The installer application 201 continues with the installation process 
until all of the resources of the product are written to the appropriate 
location on the hard disk drive 27. After all of the resources are written, the 
installer application 201 creates a "source list" 212 in the installer registry 
202. If, after installation, the source 215 is needed by the installer 
application 201, the source list 212 identifies where the source 215 may 
be found. The initial locations 214 contained in the source list 212 may be 
derived from information contained in the product package 213, in addition 
to the location of the product package 213. The first location in the source 
list 212 is likely to be the location of the source 215 during the present 
installation, here the CD-ROM disk 31 within the optical disk drive 30. The 
source list 212 includes a list of alternative locations where the source 215 
may be located should the source 215 not be found in the first location 
searched. The locations may be any location on any media accessible by 
the computer 20, including on a floppy disk 29, CD-ROM disk 31, network 
server accessible via a LAN 51, a File Transfer Protocol (FTP) site on the 
Internet accessible via modem 54 or LAN 51, or any other storage media 
now known or hereafter developed. 



The portion of Chamberlain shown above merely teaches that the "installer 
application 201" creates a "source list 212" that identifies where the "source 215" may 
be found during the installation of a "product". Chamberlain teaches, at column 7, lines 
46-60, that "source 215" contains the actual "resources" associated with a product. 
Chamberlain identifies "resources as "...program files, registry entries, shortcuts, etc...." 
at column 7, lines 43-45. Therefore, Chamberlain teaches that the "source list 212" 
provides one or more locations at which a "program file", "registry entry", "shortcut" for a 
"product" may be found. Chamberlain does not, however, teach or suggest that any of 
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the "program file", "registry entry", "shortcut", which the Office has alleged are 
associated with one or more locations, make any sort of "request" for a service, not 
even a request to perform a "component update", which the Office has identified as the 
aspect of Tavis alleged to teach Applicant' "service" claim element. 

In addition, neither Chamberlain nor Tavis teach a one-to-one association, as 
recited by Applicant's claim 1. Chamberlain states, at column 9, line 61 to column 10, 
line 5: 

The source list 212 is used today in the case where an application 
has already been partially or completely installed, and a subsequent install 
is later invoked on that product that requires the source 215. When this 
subsequent install is invoked, the user is not really installing from any one 
place. Therefore, locations in the source list 212 are searched, and the 
first location having the source 215 is used for the install . For example, if 
the network is down, the original source may not be available. Likewise if 
the user originally installed from CD, and the CD is not in the CD-ROM 
drive, then the source list 212 can be used to find alternate source 
locations, 
(emphasis added) 



Therefore, Applicant respectfully submits Chamberlain does not teach or suggest 
"...interactions between one of a plurality of software components in an electronic 
device and an associated one of a plurality of servers . nor does Chamberlain teach 
or suggest "...a prior registration associating the one of the plurality of servers with the 
one of the plurality of software components making the at least one request for service ; 
as recited by Applicant' claim 1. 

Moreover, Applicant respectfully submits that the Office has not provided any 
explanation of how the teachings of Chamberlain would be combined with Tavis to yield 
the invention of Applicant's claim 1. Instead, the Office simply makes the conclusory 
statement that "[i]t would have been obvious to one of ordinary skill in the art at the time 
the invention was made to modify the invention of Tavis to incorporate the features of 
Chamberlain." See Office action at page 5. M.P.E.P. §2142, however, makes it clear 
that "[t]he key to supporting any rejection under 35 U.S.C. 103 is the clear articulation of 
the reason(s) why the claimed invention would have been obvious...", and that "[t]he 
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Supreme Court in KSR International Co. v. Teleflex Inc., 127 S. Ct. 1727 (2007), 82 
USPQ2d 1385, 1396 noted that the analysis supporting a rejection under 35 U.S.C. 103 
should be made explicit." Therefore, for at least the reasons set forth above, the Applicant 
respectfully submits that the Office has failed to establish a prima facie case of 
obviousness, and that claim 1 is allowable. 

Based at least upon the above, Applicant respectfully submits that the Office has 
failed to establish a prima facie case of obviousness, as required by M.P.E.P. §2142, 
and that claim 1 is allowable over the proposed combination of references. Applicant 
believes that claims 2-15, which depend from independent claim 1 are also allowable, 
for at least the reasons set forth above. Accordingly, Applicant respectfully requests 
that the rejection of claims 1-15 under 35 U.S.C. §1 03(a) be reconsidered and 
withdrawn. 

With regard to the rejection of independent claim 16, Applicant respectfully 
submits that claim 16 recites "[a] wireless communication system supporting at least 
one electronic device, the system comprising: a service broker communicatively 
coupled to the at least one electronic device; a plurality of service providers, each of the 
plurality of service providers communicatively coupled to the service broker; a client- 
side component in the at least one electronic device that requests a software update 
from one of the plurality of service providers; and wherein the service broker determines 
the appropriate one of the plurality of service providers to respond to the software 
update request, based upon an association of the one of the plurality of service 
providers with the client-side component that made the request." 

Applicant respectfully submits that independent claim 16 recites elements similar 
in many ways to those recited by independent claim 1 , and that the Office cites many of 
the same teachings of Tavis and Chamberlain in the rejection of claim 16, as were cited 
in the rejection of claim 1 . Accordingly, Applicant respectfully submits that independent 
claim 16 is allowable over the proposed combination of Tavis and Chamberlain, for at 
least the reasons set forth above with respect to the rejection of independent claim 1 . 
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Further, because claims 17-21 depend from allowable independent claim 16, Applicant 
respectfully submits that claims 17-21 are also allowable, for at least the same reasons. 
Accordingly, Applicant respectfully requests that the rejection of claims 16-21 under 35 
U.S.C. §1 03(a) be reconsidered and withdrawn. 

With regard to the rejection of independent claim 22, Applicant respectfully 
submits that claim 22 recites "[a] method for updating at least one of a software 
component and software component configuration information in an electronic device 
communicatively coupled to a service broker, the method comprising: under the control 
of the electronic device, registering at least one call-back function available in the 
software component, wherein each of the at least one call-back function is associated 
with a server; communicating, to the service broker, a request for updating of at least 
one of the software component and software component configuration; receiving results 
from a remote service provider; and invoking the at least one call-back function using 
the received results; and under the control of the service broker, receiving an update 
request; determining a service provider based upon the update request; invoking update 
functionality on the determined service provider; and transmitting results of the invoked 
update functionality to the mobile device." 

Applicant respectfully submits that independent claim 22 recites features similar 
in many respects to those recited by independent claims 1 and 16, and that the Office 
cites many of the same teachings of Tavis and Chamberlain in the rejection of claim 22 
as were cited in the rejections of claims 1 and 16. Accordingly, Applicant respectfully 
submits that independent claim 22 is allowable over the proposed combination of Tavis 
and Chamberlain, for at least the reasons set forth above with respect to the rejections 
of independent claims 1 and 16. Further, because claims 23 and 24 depend from 
allowable independent claim 22, Applicant respectfully submits that claims 23 and 24 
are also allowable, for at least the same reasons. Accordingly, Applicant respectfully 
requests that the rejection of claims 22-24 under 35 U.S.C. §1 03(a) be reconsidered 
and withdrawn. 
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Conclusion 

In general, the Office Action makes various statements regarding the claims and 
the cited references that are now moot in light of the above. Thus, the Applicant will not 
address such statements at the present time. However, the Applicant expressly 
reserves the right to challenge such statements in the future should the need arise (e.g., 
if such statements should become relevant by appearing in a rejection of any current or 
future claim). 

The Applicant believes that all of pending claims 1-24 are in condition for 
allowance. Should the Examiner disagree or have any questions regarding this 
submission, the Applicant invites the Examiner to telephone the undersigned at (312) 
775-8000. 

A Notice of Allowability is courteously solicited. 

Respectfully submitted, 



Dated: July 17. 2008 /Kevin E. Bora/ 

Kevin E. Borg 
Reg. No. 51,486 

Hewlett-Packard Company 
Intellectual Property Administration 
Legal Department, M/S 35 
P.O. Box 272400 
Fort Collins, CO 80527-2400 
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